Build against networknt json-schema-validator 3.x - #24
Conversation
networknt 3.x replaced its Jackson 2 node API with Jackson 3 and removed the
getSchema/validate(JsonNode) overloads this library called, so consumers that
put networknt 3.x on the classpath hit NoSuchMethodError when the first schema
is compiled. Feed networknt JSON text via its InputFormat.JSON entry points,
move the custom Format validators to Jackson 3 nodes, and pin the Jackson 3 BOM
to the version networknt depends on. The public API is unchanged.
One behaviour change: a value beyond Double.MAX_VALUE is now rejected as a type
error ("number expected") rather than reaching the custom double-format
validator. The value is still rejected.
Refs atlassian#21
|
Hooray! All contributors have signed the CLA. |
|
LGTM. Thanks for the contribution! We had a go at this in the v3 branch, but this is a really nice solution. FYI I no longer work for Atlassian (as of a month ago) so I can't approve the PR. @agustafson-atl might be able to help get this over the line. |
Got it, thanks for spending time on this anyway. 🙇🏻 |
|
Hey guys how does it look here? Based on contribution graph it looks like you @jfnavin were maintaining this library almost single-handedly for the past years (thank you for all your work!), do you know if we can expect some continuity from Atlassian in this library or if the safest bet is to fork our own version if we want to proceed with this fix? Thanks. |
|
Maybe worth giving a gentle poke at @agustafson-atl on this. 🙂 |
….1-pb.1) Retarget coordinates com.atlassian.oai -> io.github.productboardlabs across all reactor modules and set version 3.0.1-pb.1, point SCM/url at the fork, and add the Sonatype central-publishing-maven-plugin (publishingServerId=central, autoPublish=true) mirroring productboardlabs/jackson-kafka-avro-serializer so `mvn clean deploy` publishes to Maven Central. Builds on top of the networknt 3.x migration (PR atlassian#24) so swagger/OpenAPI request validation is compatible with Jackson 3 / networknt 3.x. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…schema-validator-pin Koppel de pin (pom.xml) en de Dependabot-ignore aan de upstream-PR waarmee openapi-request-validator naar networknt json-schema-validator 3.x migreert, zodat het moment om te un-pinnen vindbaar blijft: atlassian/openapi-request-validator#24 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
….0.6 (#138) * build(deps): Bump com.networknt:json-schema-validator Bumps [com.networknt:json-schema-validator](https://github.com/networknt/json-schema-validator) from 2.0.1 to 3.0.6. - [Release notes](https://github.com/networknt/json-schema-validator/releases) - [Changelog](https://github.com/networknt/json-schema-validator/blob/master/CHANGELOG.md) - [Commits](networknt/json-schema-validator@2.0.1...3.0.6) --- updated-dependencies: - dependency-name: com.networknt:json-schema-validator dependency-version: 3.0.6 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> * fix(deps): pin json-schema-validator op 2.0.1 (compat openapi-request-validator) De Dependabot-bump naar 3.0.6 (semver-major) is binair incompatibel met openapi-request-validator 3.0.0: networknt 3.x wijzigt de publieke API (SchemaRegistry.getSchema-signatuur) -> NoSuchMethodError in alle contracttests. Terug naar 2.0.1, de versie waartegen openapi-request-validator is gecompileerd. De pin staat centraal in dependencyManagement en overschrijft ook WireMock's nabijere transitieve 1.5.9 (nearest-wins); de losse per-service declaraties waren daarmee overbodig en zijn verwijderd. Dependabot negeert voortaan major-bumps van deze dependency tot openapi-request-validator meebeweegt. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * docs(deps): verwijs naar upstream networknt-3.x-migratie bij de json-schema-validator-pin Koppel de pin (pom.xml) en de Dependabot-ignore aan de upstream-PR waarmee openapi-request-validator naar networknt json-schema-validator 3.x migreert, zodat het moment om te un-pinnen vindbaar blijft: atlassian/openapi-request-validator#24 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Eric Wout van der Steen <92432523+ericwout-overheid@users.noreply.github.com> Co-authored-by: Mark Reuvekamp <mark.reuvekamp@rijksoverheid.nl> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Hey @stefanobaghino (and possibly others). Since the repo seems abandoned (for now), we have published our own fork which contains changes in this PR to unblock future dependency upgrades. For now we are publishing just subset of the packages, if anyone would need it we can extend it to all of them I guess. No future extensions of our fork are planned (for now). https://central.sonatype.com/artifact/io.github.productboardlabs/openapi-request-validator Cheers |
3 participants
Consumers that put networknt json-schema-validator 3.x on the classpath alongside this library hit a
NoSuchMethodErrorthe first time a schema is compiled: 3.x replaced its Jackson 2 node API with Jackson 3 and removed thegetSchema/validate(JsonNode)overloads this library calls. This builds the library against networknt 3.x so the two stay compatible.swagger-parser still produces Jackson 2 nodes while networknt 3.x consumes Jackson 3, so the schema and the instance are handed to networknt as JSON text through its
InputFormat.JSONentry points; the customFormatvalidators move to Jackson 3 nodes. The transformer pipeline, the 3.0/3.1 dialect split, and thecom.atlassian.oai.validator.*public API are unchanged.One behaviour change: a value beyond
Double.MAX_VALUEis now rejected as a type error ("number expected") rather than reaching the customdouble-format validator. The value is still rejected; only the error key differs.Opening as a draft pending the two questions in #21 (text boundary vs. node conversion; whether the
format.double→typechange is acceptable), and before the Atlassian CLA is signed.Closes #21